EXPOSING BLUETOOTH COMPLIANT WIRELESS DEVICE CONNECTIONS 

AS MODEMS OR SOCKETS 



5 TECHNICAL FIELD 



his invention relates generally to wireless interface technology and, more 
particularW, relates to the interface between computer software applications and wireless 
devices operating in accordance with the Bluetooth specification. 

10 BACKGROUND OF THE INVENTION 

To provide the greatest compatibility between software and hardware components 
on a computer system, the operating system of the computer defines certain interfaces 
which can be accessed and used by the programmers of the software components and 
which are to be provided and supported by the designers of hardware components. Thus, 
15 by using the defined interface, the software component can be assured of compatibility 
with all of the hardware components which support the interface. Similarly, a hardware 
component providing a specific interface can be assured that software components will be 
able to locate and access the fiinctionality provided by the hardware component through 
the interface. 

2 0 Generally, computers and other electronic devices are interconnected via physical 

cables or wires. These communication paths allow for the exchange of data or control 
information between such devices. However, it is increasingly recognized that certain 
advantages arise fi'om the elimination of cables and wires to interconnect devices. Such 
advantages include ease of configuration and reconfiguration, due to the elimination of 

25 the need to physically add, remove, or displace a physical medium. Furthermore, space 
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which would traditionally be used for device interconnection media may be given to other 
uses. Furthermore, device mobility is increased through the use of wireless connections. 

One method for providing wireless connections between devices employs a light 
wave in the Infrared region of the electromagnetic spectrum to link devices. The IrDA 
5 (Infrared Data Association) protocol defines one such connection mechanism. 

Unfortunately, such a mechanism must usually operate in a line of sight manner. That is 
to say that any opaque obstruction between transmitter and receiver will prevent proper 
operation. Additionally, IR transmitters are typically not omnidirectional when 
incorporated into a communicating device, so that for proper operation, the transmitter 
10 must be pointed generally in the direction of the receiver, within some nominal deviation 
such as 30 degrees. Finally, IR transmitters are typically fairly low power devices, and 
accordingly the range of IR links is usually limited to approximately one meter. 



^adio frequency links solve many of the problems inherent in Infrared links, 
however, ao-adio frequency connection scheme is needed whereby a variety of 
15 applications oan easily access the radio link through a connection mechanism that 

provides an appfopriate interface. One protocol which defines communication between 
wireless devices tlVough radio frequency links is the Bluetooth specification. Bluetooth 
devices do not require a line of sight with one another to operate, and their range can be 
significantly greater thafa that of IR links. However, one difficulty with the Bluetooth 
2 0 specification is that very few computer software programs are written to communicate 
with Bluetooth compliant davices. Another difficulty with the Bluetooth specification is 
that Bluetooth compliant devioes are presented to computer software programs as serial 
interfaces. There are be numerous situations it which such a serial presentation can be 




inefficient or even confusing for certain types of computer software applications, such as 
simple networking applications. Yet another difficulty with the Bluetooth specification is 
that, while it supports up to 30 emulated RS-232 ports, computer software programs are 
generall\ required to know how to communicate through such an emulated port in a 
device-speVific manner. 



SUMMARY OF THE INVENTION 

Accordingly, the present invention provides a method and computer program 
product foV providing an interface to a Bluetooth compliant device which can emulate a 
10 modem such \hat computer software programs can communicate through the Bluetooth 
compliant devicfe in the same manner in which they would communicate through a 
standard modem to\ccess a dial-up, wide area network. 
^ mS^ present invention also provides a method and computer program product for 

providing aJl interface to a Bluetooth compliant device which can emulate a network 
15 socket such that computer software programs can communicate through the Bluetooth 
compliant device seemingly in the same manner in which they would communicate 
through a standard ne^ork interface card to access a local area network. 

traditionally, the present invention provides a method by which the interface to a 
Bluetooth clompliant device is dependent on the nature of the Bluetooth compliant device. 
2 0 Additional features and advantages of the invention will be made apparent fi-om 

the following detailed description of illustrative embodiments which proceeds with 
reference to the accompanying figures. 



BRIEF DESCRIPTION OF THE DRAWINGS 

While the appended claims set forth the features of the present invention with 
particularity, the invention, together v/iih its objects and advantages, may be best 
understood from the follov^ing detailed description taken in conjunction with the 
5 accompanying drawings of which: 

Figure 1 is a block diagram generally illustrating an exemplary computer system 
on which the present invention resides; 

Figure 2 is a block diagram generally illustrating a seven-layer network model; 

Figure 3 is an architectural diagram of various system components used in an 
1 0 embodiment of the invention; and 

Figure 4 is a flow chart illustrating steps taken in an embodiment of the invention 
to interface applications of different types to a radio frequency link. 



DETAILED DESCRIPTION OF THE INVENTION 

15 Tuming to the drawings, wherein like reference numerals refer to like elements, 

the invention is illustrated as being implemented in a suitable computing environment. 
Although not required, the invention will be described in the general context of computer- 
executable instructions, such as program modules, being executed by a personal 
computer. Generally, program modules include routines, programs, objects, components, 

2 0 data structures, etc. that perform particular tasks or implement particular abstract data 
types. Moreover, those skilled in the art will appreciate that the invention may be 
practiced with other computer system configurations, including hand-held devices, multi- 
processor systems, microprocessor based or programmable consumer electronics. 



network PCs, minicomputers, mainframe computers, and the like. The invention may 
also be practiced in distributed computing environments where tasks are performed by 
remote processing devices that are linked through a communications network. In a 
distributed computing environment, program modules may be located in both local and 
5 remote memory storage devices. 

With reference to Fig. 1, an exemplary system for implementing the invention 
includes a general purpose computing device in the form of a conventional personal 
computer 20, including a processing unit 21, a system memory 22, and a system bus 23 
that couples various system components including the system memory to the processing 

1 0 unit 21 . The system bus 23 may be any of several types of bus structures including a 

memory bus or memory controller, a peripheral bus, and a local bus using any of a variety 
of bus architectures. The system memory includes read only memory (ROM) 24 and 
random access memory (RAM) 25. A basic input/output system (BIOS) 26, containing 
the basic routines that help to transfer information between elements within the personal 

15 computer 20, such as during start-up, is stored in ROM 24. The personal computer 20 
further includes a hard disk drive 27 for reading from and writing to a hard disk 60, a 
magnetic disk drive 28 for reading from or writing to a removable magnetic disk 29, and 
an optical disk drive 30 for reading from or writing to a removable optical disk 3 1 such as 
a CD ROM or other optical media. 

2 0 The hard disk drive 27, magnetic disk drive 28, and optical disk drive 30 are 

connected to the system bus 23 by a hard disk drive interface 32, a magnetic disk drive 
interface 33, and an optical disk drive interface 34, respectively. The drives and their 
associated computer-readable media provide nonvolatile storage of computer readable 



instructions, data structures, program modules and other data for the personal computer 
20. Although the exemplary environment described herein employs a hard disk 60, a 
removable magnetic disk 29, and a removable optical disk 31, it will be appreciated by 
those skilled in the art that other types of computer readable media which can store data 
5 that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital 
video disks, Bernoulli cartridges, random access memories, read only memories, and the 
like may also be used in the exemplary operating environment. 

A number of program modules may be stored on the hard disk 60, magnetic disk 
29, optical disk 31, ROM 24 or RAM 25, including an operating system 35, one or more 

1 0 applications programs 36, other program modules 37, and program data 38. A user may 
enter commands and information into the personal computer 20 through input devices 
such as a keyboard 40 and a pointing device 42. Other input devices (not shown) may 
include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and 
other input devices are often connected to the processing unit 21 through a serial port 

1 5 interface 46 that is coupled to the system bus, but may be connected by other interfaces, 
such as a parallel port, game port or a universal serial bus (USB). A monitor 47 or other 
type of display device is also connected to the system bus 23 via an interface, such as a 
video adapter 48. In addition to the monitor, personal computers typically include other 
peripheral output devices, not shown, such as speakers and printers. 

2 0 The personal computer 20 may operate in a networked environment using logical 

connections to one or more remote computers or devices, such as a remote computer 49 
or RF device 64. The remote computer 49 may be another personal computer, a server, a 
router, a network PC, a peer device or other common network node, and typically 
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includes many or all of the elements described above relative to the personal computer 
20, although only a memory storage device 50 has been illustrated in Fig. 1 . The Radio 
Frequency (RP) device 64 can be a cellular phone, digital camera, another personal 
computer, or other device which includes the capability to communicate through the RF 
5 spectrum. The logical connections depicted in Fig. 1 include a local area network (LAN) 
5 1 and a wide area network (WAN) 52, and an RF connection 63. Such networking 
environments are commonplace in offices, enterprise-wide computer networks, intranets 
and the Internet. 

When used in a LAN networking environment, the personal computer 20 is 
10 connected to the local network 5 1 through a network interface or adapter 53. When used 
in a WAN networking environment, the personal computer 20 typically includes a 
modem 54 or other means for establishing communications over the WAN 52. The 
modem 54, which may be internal or external, is connected to the system bus 23 via the 
serial port interface 46. When used in conjunction with an RF connection 63, the 
15 personal computer 20 includes an RF interface 62. In a networked environment, program 
modules depicted relative to the personal computer 20, or portions thereof, may be stored 
in the remote memory storage device. It will be appreciated that the network connections 
shovm are exemplary and other means of establishing a communications link between the 
computers may be used. 
20 In the description that follows, the invention will be described with reference to 

acts and symbolic representations of operations that are performed by one or more 
computers, unless indicated otherwise. As such, it will be understood that such acts and 
operations, which are at times referred to as being computer-executed, include the 



manipulation by the processing unit of the computer of electrical signals representing data 
in a structured form. This manipulation transforms the data or maintains it at locations in 
the memory system of the computer, which reconfigures or otherwise alters the operation 
of the computer in a manner well understood by those skilled in the art. The data 
5 structures where data is maintained are physical locations of the memory that have 

particular properties defined by the format of the data. However, while the invention is 
being described in the foregoing context, it is not meant to be limiting as those of skill in 
the art will appreciate that various of the acts and operations described hereinafter may 
also be implemented in hardware. 
10 In accordance with the invention, and turning to Figure 2, the Open Systems 

■; 

Interconnection (OSI) seven-layer model is shown. This model is an industry standard 
Tf^ abstraction of computer networking. The application layer 100 directly serves the end 

=== J user and supports the software applications with which the user interacts. The 

ri presentation layer 102 provides the mechanisms which interpret data being sent from the 

15 application layer 100 on one computer to the application layer on another. The session 
J;^ layer 104 describes the organization of the data being transferred. The transport layer 106 

acts as a final error correcting layer to ensure the data is delivered accurately, in the 
proper sequence, and with no loss or duplication. The network layer 108 defines the 
addressing and routing of the data across the network. It controls the operation of the 
2 0 local sub-network and decides which physical path the data should take, given network 
conditions, priority of service, and other factors. The data link layer 110 controls the 
transmission of blocks of data, or packets, across the network, and provides more 
fundamental error correction. The data link layer 1 10 is divided into two sublayers: the 




logical link control (LLC) sublayer and the media access control (MAC) sublayer. The 
LLC sublayer ensures error-free transmission of data frames by maintaining logical links, 
controlling frame flow, sequencing frames, acknowledging frames, and retransmitting 
unacknowledged frames. The MAC sublayer manages access to the network, checks 
frame errors and address recognition of the received frames. Protocols which include an 
LLC sublayer need only a minimal transport layer 106. Finally, the physical layer 1 12 
carries the signals which are sent to the network connection 1 14, Generally, the physical 
layer 112 is implemented in the hardware connecting the computer 20 to the network 
connection 114. 

A Network Device Interface Specification (NDIS) 116 can reside between the 
network layer 108 and the data link layer 110. The NDIS 116 can provide a library of 
interfaces between the software components and the hardware components. The NDIS 
116 can define a fully abstracted environment for network interface card (NIC) driver 
development by providing routines for every extemal fiinction that a NIC driver would 
need to perform. Thus, the NDIS 1 16 can provide interfaces for communication between 
a NIC driver and a overlying protocol driver and between a NIC driver and the underlying 
NIC hardware itself. 

Generally the application layer 100, presentation layer 102, session layer 104, 
transport layer 106, and the network layer 108 are implemented in software components 
operating on a computer. The data link layer 110 and the physical layer 1 12 are generally 
implemented by the hardware components, such as a network interface card. The NDIS 
116 library can be used by a software driver implemented in the transport layer 1 10 to 
communicate with a network interface card driver implemented at the data link layer 110. 
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A transport layer driver generally implements a network protocol stack, such as the well 
known Transfer Control Protocol / Internet Protocol (TCP/IP) stack used on the Internet. 
If the transport layer software driver has a packet of data to be transmitted, it can call the 
NIC driver by means of an interface from the NDIS 116 library, and pass dovm the packet 
5 to be transmitted. Similarly, the NIC driver can use an interface of the NDIS 1 16 to pass 
the packet to the NIC itself for transmission across the network. The NDIS 116 interface 
can call the operating system specific components which perform the transmission at the 
NIC. The NDIS 116 interfaces can also be used by the NIC driver to communicate with 
the transport layer software driver and pass up a received packet of data, or other 
10 information. 

^>\^^y/ i^ording to the "Specification of the Bluetooth System" Version l.OB 

(December \l 999), incorporated herein by reference in its entirety, RFCOMM supports 
up to 30 emulated RS-232 (COM) port connections between any two devices. See also 
the "Windows Wireless Architecture" presentation at Appendix B, the "Bluetooth 
15 Architecture Overview presentation at Appendix C, the "Bluetooth Experience in 
Windows" presentation a\ Appendix D, and the "Bluetooth Stack in Windows" 
presentation at Appendix e\ However, Dial -Up Networking (DUN) connections provide 
specific services that are best presented as a modem. Accordingly, when a DUN profile 
is exposed as a COM port ratheV than as a modem connection, the relevant client 
0 application must have the ability V) communicate in a device-specific way with a device. 
p\ ^ iV keeping with an embodiment of the invention, DUN services are exposed by 
RFCOMN^o the application as a modem connection, allowing the client application to 
use standard Yelephony API (TAPI) and Unimodem interfaces. Thus applications and 
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sendees which are not specifically adapted for use within the Bluetooth protocol can 
nonetheless utilize a communications device as a standard communications device, hiding 
the implementation-specific differences between Bluetooth and Dial-up Networking 
connections. 

^^"^^^^^ ^^COMM is implemented as described in the "Specification of the Bluetooth 

System" Version LOB Part Fl entitled "RFCOMM with TS 07.10 incorporated herein by 
reference iii its entirety and attached at Appendix A, with certain changes to effect the 
desired functVnality. The following components, most of which appear in the 
architectural diagram of Fig. 3, are used to expose a Bluetooth RFCOMM Dial-Up 
1 0 Networking connection as a modem rather than as a COM port: RFCOMM. SYS (the 
Bluetooth RFCOMM driver) 301; BTHPORT.SYS (the Bluetooth port driver 
implementing L2CAP and HCI.) 303; TDI (transport device interface) 305; PnP (the 
"Plug'N'Play" systemV BTHMDM.SYS (the Bluetooth modem driver) 307; and 
MODEM.SYS (the Unimodem driver) 309, As one of skill in the art will know, the 
15 Plug^N'Play system is a cdmibination of hardware and software support that enables a 

computer system to recognnf e and adapt to hardware configuration changes with little or 
no user intervention. 

When a new device conforming to the Bluetooth specification is detected by the 
computer, BTHPORT.SYS enumerates the new device as a Physical Device Object 
20 (PDO). As ils knovm by those of skill in the art, a PDO represents the whole range of 
functionality aWlable to a component. RFCOMM is alerted to this new device by way 
of BTHPORT.SYS. RFCOMM.SYS is loaded as the Functional Device Object (FDO) 



^ by the Plug'N'I 
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'Play system (PnP). As is also known by those of skill in the art, an FDO 



represents a set of functions of device available to a function driver. 

RJFCOMM examines the Service Discovery Protocol (SDP) database of the 
remote RFODMM device. If the remote device is a DUN device, RFCOMM enumerates 
5 a nev^ PDO. For Bluetooth LAN access points and PC's acting as LAN access points, 
RFCOMM. SYS enumerates a PDO that will load an instance of a Null modem device in 
BTHMDM.SYS. FofsBluetooth modems acting as a Gateway (GW), RFCOMM.SYS 
will enumerate a PDO that will load an instance of a modem device in BTHMDM.SYS. 
BTHMDM.SYS communic^s to RFCOMM using 10 request packets (IRP's) via the 

1 0 TDI interface. Alternatively, B^MDM.SYS may communicate with IRP's that are not 
restricted to TDI requests, but that ate still Windows Driver Model (WDM) requests. 

BTHMDM.SYS exposes an interface to MODEM.SYS that provides a functional 
equivalent of the standard Windows 2000 SERIAL.SYS driver. This has the effect of 
emulating an RS-232 modem connection from the viev^oint of MODEM.SYS. 

15 MODEM.SYS then provides a Unimodem interface to Unimodem clients such as TAPI, 
allowing the device to be addressed as a standard communications device, e.g. a modem. 

To permit peer-to-peer DUN communications between two PC's, it is preferable 
that one oiythe PC*s acts as a server. The server PC preferably populates its SDP database 
with and appropriate DUN entry so that the client can identify and connect with it. This 

20 is preferably pWormed at the time that the RFCOMM driver loads, either at system start 
up, or at the tim& that the Bluetooth device is connected to the system. RFCOMM.SYS 
will automaticallyVenerate a PDO to represent the server channel to BTHMDM.SYS, 
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such \hat the server software may be initialized and ready to handle an incoming 
connection request. 

When a cHent attempts to connect to the DUN server, BTHPORT.SYS will 
generate a PDO to represent the new connection. RFCOMM will create an FDO and 
associate it with the new PDO. However, instead of generating a new PDO for the 
modem driver, RFCOMM will associate the new PDO and FDO with the already existing 
PDO being handled by the DUN server. 

communication mechanism described above with reference to Bluetooth 



DUN connections also applies to dependant profiles such as the LAN access profile and 

10 theFAXprofil 

According to another embodiment of the invention, RFCOMM is alerted to a new 
connection by BTHPORT.SYS, as was described in more detail above. If, after 
examining the SDP database of the new connection, as described above, RFCOMM 
determines that the connection is not a dial-up networking device, RFCOMM will allow 

15 access to the device through the RFCOMM TDI interface. As is known by those of skill 
in the art, the TDI is the interface which allows higher level components access to the 
transport layer, which was described in more detail above. This access is extended to the 
user mode level by AFD.SYS. It is AFD.SYS which provides this access to WinSock. In 
such a manner, the new device is assigned its own socket and treated in a manner 

2 0 analogous to a network card. 

Each transport protocol defines an address that describes endpoint information 
associated with address objects that are open in the transport layer. The TDI address of 
an RFCOMM endpoint can be defined as follows: 



#define BTH_ADDR_LEN 4 8 

#define BTH_ANY_CHANNEL_NUMBER (UNLONG) -1 

typedef BD_ADDR UCHAR [BTH_ADDR_LEN] 

5 

typedef struct TDI_ADDRESS_BLUETOOTH { 

ULONG ChannelNumber ; 

BD_ADDR BdAddr; 
} TDO_ADDRESS_BLUETOOTH ; 

10 

Where the TDI_ADDRESS_BLUETOOTH type defines an RFCOMM channel number 
of the endpoint, if it is supported by the RFCOMM stack. Alternatively, ChannelNumber 
can specify an L2CAP channel number. 

As described above, the TDI allows higher level components to access the 

15 transport layer. Such a higher level component is known as a client of the TDI. A client 
of the TDI can open a server endpoint for accepting incoming connections by any number 
of methods. One method for doing so is to include a TDI_ADDRESS_BLUETOOTH 
with a ChannelNumber of either BTH_ANY_CHANNEL_NUMBER or an RFCOMM 
channel number between one and thirty. Specifying BTH_ANY_CHANNEL_NUMBER 

2 0 will let RFCOMM select an unused channel number. If the client manually selects a 
channel number and it is in use, the opening of the address object will fail with 
TDI_ADDR_IN_USE. BdAddr can be set to zero. Another method of opening a server 
endpoint for accepting incoming connections is to open a connection object and associate 
it with the above address object. This will be the connection object for the first incoming 

2 5 connection. Because RFCOMM can limit a server charmel to just one connection per 
remote device it is generally not necessary to create a backlog of connection objects for 
incoming connections. After accepting an incoming connection, the TDI client can 
simply create another connection object and associate it with the above address object for 
the next incoming connection. 



A TDI client can also open a connection to a remote device through a number of 
methods. One method for doing so is to open an address object, including a 
TDI_ADDRESS_BLUETOOTH with a ChannelNumber set to zero. A ChannelNumber 
of zero indicates that the address object will be used for an outbound connection and the 
stack will not reserve a server channel number for it. BdAddr can be set to zero. Another 
method of opening a connection to a remote device is to open a connection object and 
associate it with the address object. Yet another method of opening a connection to a 
remote device is to issue a TDI connect request IRP on the connection object. The IRP 
will contain a TDI_ADDRESS_BLUETOOTH with the BdAddr of the remote device and 
the destination ChannelNumber. 



^ Existing implementations of the Bluetooth specification map remote devices to a 
generic serial-type device. Unfortunately, proper configuration of such a system requires 
user knowledge regarding serial port technology. In an embodiment of the present 
invention, RFCQMM connections of a particular type are automatically routed to an 
appropriate corresponding device type within the Microsoft brand WINDOWS operating 
system using the SDl\ Broadly, if a device is not a DUN device, then RFCOMM will 
allow access to that devite through the TDI interface. This access is extended to user 
mode by AFD.SYS (standard Winsock service provider for transports). In order to allow 
TDI's addressing model to mmtiplex multiple cormections to the same RFCOMM 
channel on different RFCOMJ^essions, the RFCOMM channel number/remote 
Bluetooth address pair of the endppint uniquely identifies each RFCOMM connection. In 
contrast to the DUN profile, Winsook and AFD will be required to create device objects 
and handles in a mechanism consistenV with existing TDI applications. 




In greater detail, with reference to step 201 of Fig. 4, BTHPORT.SYS initially 
enumerates a new device PDO. Subsequently, in step 203, RFCOMM.SYS 
is loaded as the functional driver for this PDO. In step 205, RFCOMM.SYS examines 
the SDP data base of the remote device to determine device type. If in step 207 it is 
5 determined that the device is a DUN device, then in step 211 RFCOMM.SYS enumerates 
a PDO that has MODEM.SYS as its functional driver and BTHMDM.SYS as a lower 
filter driver. Otherwise, in step 209, the device is exposed to an API such as Windows 
Sockets via the TDI interface. 

All of the references cited herein, including patents, patent applications, and 
1 0 publications, are hereby incorporated in their entireties by reference. 

In view of the many possible embodiments to which the principles of this 
invention may be applied, it should be recognized that the embodiment described herein 
with respect to the drawing figures is meant to be illustrative only and should not be 
taken as limiting the scope of invention. For example, those of skill in the art will 
15 recognize that the elements of the illustrated embodiment shown in software may be 
implemented in hardware and vice versa or that the illustrated embodiment can be 
modified in arrangement and detail without departing from the spirit of the invention. 
Therefore, the invention as described herein contemplates all such embodiments as may 
come within the scope of the following claims and equivalents thereof. 



